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ABSTRACT 

It is only recently that research in artificial intelligence 
(AI ) is accomplishing practical results. Most of these results 
can be attributed to the design and use of expert systems (or 
Knowledge Based Systems, KBS) - problem solving computer programs 
that can reach a level of perfo rma nee c omp arable to that of a 
human expert in some specialized problem domain. But many 
computer systems designed to see images, hear sounds and 
recognize speech are still in fairly early stage of deve 1 opment . 

In this report, a preliminary survey of recent work in KBSs 
is reported, explaining KBS concepts and issues and techniques 
used to construct KBS. Application considerations to construct 
KBSs and potential research areas in KBSs are identified. A case 
study (MYCIN) of a KBS is also provided. 
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Within this report, certain survey sections are based heavily on 
state-of-the-art research reported on by other authors. Such 
section titles within the report are followed inxnediately by 
cited references indicating that credit for the contents of the 
entire section is due to the cited author(s). 
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KNOLEDGE BASED SYSTEMS: 

A PRELIMINARY SURVEY 
OF 

SELECTED ISSUES AND TECHNIQUES 


1 . INTRODUCTION 

It is only recently that artificial intelligence (AI ) - that 
branch of computer science that attempts to have machines emulate 
intelligent behavior - is acc omp lishing practical results. Mo s t 
of these results can be attributed to the design and use of 
expert systems (or Knowledge-Based Systems, KBS ) - problem 
solving computer programs that can reach a level of performance 
comparable to that of a human expert in some specialized problem 
domain [Nau, 83]. 

This project report surveys recent work in KBS, explaining 
KBS concepts and issues. 

2. KNWVLEDGE-BASED SYSTEMS (KBS) 

It is necessary to distinguish, at the outset, between 
knowledge-based systems and other computer-based systems that 
contain or incorporate knowledge. Almost all computer programs 
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and systems contain knowledge of at least two kinds: knowledge 
about things and knowledge about what to do with things - that 
is, how to manipulate or transform them. Davis [Davis, 77] 
defines the KBS in the following way: ’A knowledge-based system 
is one in which knowledge is collected in one or more 
compartment s (called knowledge sources) and is of the kind that 
facilitates problem solving (reasoning) in a single, 
well-de f ined problem domain.* 

Problems are solved by applying the kind of reasoning that 
is used by a practitioner in the domain in which KBS is applied. 
Unlike generalized problem solving system, KBS must accumulate 
large amounts of knowledge in a specific domain and rely on 
doma i n- s pe c i f i c problem solving techniques that can be developed 
to a high level of expertise [Davis, 77]. 

In building such systems, researchers have found that 
amassing a large amount of data rather than sophisticated 
reasoning techniques is responsible for most of the power of the 
system. Such expert systems, previously limited to academic 
research 'projects, are beginning to enter the software market 
place [Gevarter, 83]. Some of the application areas where KBS 
are used are: 
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( 1 ) ’ Me dical diagnosis. 

(2) Mineral exploration. 

(3) Oil-well log interpretation. 

(4) Chemical and biological synthesis. 

(5) Military threat assessment. 

(6) Planning and scheduling. 

(7) Signal interpretation. 

(8) Air-traffic control. 

( 9 ) VLS I design. 

(10) Equipment fault diagnosis. 

(11) Speech understanding. 

(12) Space defence. 

(13) KB access and management. 

Table 2-1, taken from [Nau, 83], lists few of the existing 
systems developed for some problem areas. More extensive lists 
can be found in [Gevarter, 83]. 
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In addition to these systems, some compiler languages are 
being developed to provide tools for creating knowledge-based 
systems: AGE [Nii, 79], ARS [Stallman, 77], KRL [Bobrow, 77], OPS 
[Forgy, 77]. 

Speech-understanding systems developed at CMU (among other 
places) are not included in this survey [Stefik, 77; Reddy, 73; 
Reddy, 75]. This is because they are more complex and more of 
research prototypes, yet many of the techniques they embody are 
incorporated in systems discussed in this report. 
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Table 2-1 SCME EXISTING EXPERT SYSTEMS [Nau , 83] 


SYSTEM 

EXPERTISE 


AQ1 

Di agno s i 

s of Plant Di 

s e a s e s 

CASNET 

Me d i c a 1 

Cons u 1 1 i ng 


DENDRAL 

Hypo the s 

i z i ng Mo 1 e cu 1 

ar Structure 


f r om Ma s 

s Spectrograms 

DIPMETER ADVISOR 

Oil Exp 1 

oration 


EL 

Analyzing Electrical 

Circuits 

INrERNIST 

Me d i c a 1 

Cons u 1 1 i ng 


KMS 

Me d i c a 1 

Cons u 1 t ing 


MACSYMA 

Ma t h ema t 

i c a 1 F o rmu 1 a 

Manipulat ion 

MIX 

Me d i c a 1 

Cons u 1 1 i ng 


M)LGEN 

P 1 ann i ng 

; DNA Experiments 

MYCIN 

Me d c i a 1 

Consul ting 


PROSPECTOR 

Mineral 

Explorat ion 


PUFF 

Me d i c a 1 

Consul ting 


R1 

Computer 

• Configuration 
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Before we go to next section, I think it’s appropriate to 
"define” knowledge. The following is taken from [Wiederhold, 
84]. Widerhold observes that: 

(1) Knowledge considers general aspects of data. 

(2) Knowledge is significantly smaller than data. 

(3) Knowledge does not vary rapidly (compared to data). 

Widerhold gives some simple examples to illustrate the 
difference between knowledge and data: 

Mr. Lee’s age is 43 years - Data 

Middle-age is 35 to 50 - Knowledge 

People of middle-age are careful - Knowledge 

Mr. Lee has never had a traffic accident - Data 
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2.1 A Hypothetical KBS 

The following is a brief description and example of a 
simple, hypothetical KBS application that illustrates most of the 
capabilities of a KB system. This is mostly based on [Davis, 77]. 

The hypothetical system is an automotive service consultant 
whose primary purpose is to help ensure the best service at the 
least cost for automobiles brought to a service agency. The 
system is to be used both by the service representative, who is 
the primary interface between the customers and the company, and 
by the mechanics who work on the cars. Although the reasoning 
skills required by such a KB system are relatively simple, the 
amount of knowl edg e required (exclusive of the normal data 
base) is large because of the number and variety of automotive 
subsystems involved and the high degree of their interdependence. 

The data base of the system would contain a description of 
each car serviced at the agency. The description would contain 
the configuration of the vehicle’s engine, running gear, and 
optional and special equipment as well as the year of 
manufacture, model, color, service history, etc. 

The system would contain two basic kinds of knowledge: 
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(1) Generic knowledge about the major elements of the 
vehicle (such as its cooling, ignition, and fuel 
sy s t ems ) . 

(2) Knowledge about the model and its specific options. 

Diagnostic knowledge would be necessary to relate symptoms 
to causes and to relate specific knowledge to generic knowledge. 
For instance, poor engine perfo rma nee could result fr om 
mechanical problems (valves, rings) or from related systems 
(cooling, ignition, or c a r bur e t i on ) . 

The intent of the system is to reconmend: 

(1) The least expansive tests that will produce the 
greatest amount of specific information about the 
cause of the problem. 

(2) The least expensive repairs for the problem. 

(3) The best post-repair testing to verify that the 
problem is solved. 

The following is a hypothetical scenario of such a system in 
operation. The users are the service representative and the 
mechanic(s) performing the test and repair work. The user 
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language is a stylized English designed to convey a maximum 
amount of information between the user and the system with a 
minimum amount of effort. 



Change oil and filter - last changed on Jan 13, 
1977 at 24,842 mi. 

May we be of other service? 


I DBMS. NASA/ RECON- 5 I 


13 


I KNOWLEDGE- BASED I 


I NASA I 


I N A S A I 


Service rep : Battery not keeping charge, barely able to 
start car this a .m. 

System : Any other symptoms or problems? 

Service r ep : No 

Sy s t em : Check belt tension on alternator - most likely 

cause . 

Ser vice r ep : Why? 

Sy_st_em: Last service required removal of fan and belts, 

very likely that tension was not properly set 
on reinstallation. 

Service rep : More (meaning more things to be checked or 
tested) 

Sy s t em : Ch eck fluid level in battery - next mo st likely 

cause - overcharged battery. If level is low, 
check alternator output and voltage regulator. 

Service rep : Replace battery? 

Sv s t em : No, battery is 6 mo s old and should take 

recharge . 
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Service rep : Thank you. (Signal to system that session is 
ended for now) 


Sys t em : Car assigned number 287 in control system. 

First test to be performed by J.K. Uzzi in Bay 
17 . 

After the car is moved to the mechanic’s work area and the 
prescribed tests are performed, the following interchange 
takes place between the mechanic an' the system: 


Mechani c : JKU 17, 287 (indicating mechanic, bay and car 

being serviced) 


1974 Gran Torino, test results please. 


Belt tension OK, battery level OK, charge low, 
alternator, VR output OK. Problem not found. 


S y s t em : Test for above-normal current flow with 

ignition off. (Mechanic attaches amneter and 
take s reading ) . 


Mechani c : Reading above normal. 


Sy s t em : Check for faulty switch in hood light, trunk 

light, and courtesy lights. 
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Mechanic finds faulty switch in trunk light such that light 

never turns of f . 

Me c h a n i c : Fault trunk light switch R&R . Current reading 

norma 1 . 

What specific knowledge must such a system incorporate in 
order to diagnose and suggest remedies? The knowledge must come 
from experts who have acquired and demonstrated diagnostic 
skills. For the system to have suggested checking the belt 
tension of the alternator, it would have to know that the earlier 
removal of the belt could be related to the present problem, that 
the severity of the problem would depend on how poorly the 
tension was adjusted, and that one month and about 900 miles 
before appearance of symptoms (battery failure) is not 
unreasonable. Since it is a highly probable cause and the 
easiest to test, it ranks as the first suggestion. By requesting 
more information, the service representative can tell the owner 
what else may be required and what will not likely be required, 
such as a new battery. 

Even though this is an hypothetical system, functionally it 
is similar to many successful KB systems existing today. Of 
course, those systems solve more difficult problems in the sense 
that the reasoning chains may be longer. The knowledge, however. 
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is of a similar variety, and the interactive discourse has the 
same flavor of naturalness. 

2.2 KBS Components 

A knowledge-based system is one that supports practitioners 
in a specific knowledge domain by incorporating the knowledge 


acquired fr om 

experts 

in that 

d oma i n 

and 

applying it. 

i n 

combination with 

certain 

reasoning 

skills, 

t o 

the solution 

of 

problems posed 

by the 

practitioners. 

In 

other words , a 

KBS 


functions as an intelligent assistant - a substitute for the 
expert human consultant who may be needed but unavailable. A KBS 
may produce solutions or explanations that are more thorough than 
those produced by a human expert, and may produce them more 
rapidly [Gevarter, 83]. However, the human has imagination and 
the capacity for innovation which even the most expert KBS does 
no t have . 

A KBS is composed of three components or modules: 

( 1 ) "An interface . 

(2) A cognitive engine. 

(3) A knowledge base (Figure 2-1). 
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The knowledge base - the passive element in the system - 
contains the knowledge sources and fact files. 

The cognitive engine drives the system. It performs the 
system’s problem solving (inference-making or reasoning) 
operations. It applies the knowledge in the knowledge sources and 
uses the fact files in the knowledge base to answer questions or 
solve the problem posed by the user. 

The interface provides interactive conmunication between the 
user and the system. It allows for the acquisition of data in a 
variety of forms - a real-time signal, a file of observations, 
data provided by the user, etc, and for the addition or 
modification of knowledge in the knowledge base. 

As already mentioned above, a KBS acts as a special-purpose 
"intelligent agent” on behalf of its user; it is not a 
general-purpose problem solver. It provides supportive knowledge 
in a well-defined, clearly bounded problem domain. No 
present-day KBS is intended for use by a casual, inexpert user. 
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2.3 Knowledge Base 

As already mentioned, the Knowledge Base (KB) is a passive 
element of KBS. Though passive, the KB determines the 
performance and utility of the KBS, because the Cognitive Engine 
(CE) (see Section 2.4) depends on the knowledge in the KB. In 
this section, the characteristics of the KB that are c onrno n to 
many of the KB systems (that I studied) are described. 

The KB of a KBS may contain both Knowledge Sources (KSs) and 
fact files. The fact files that are contained in a KB are 
equivalent to a data base in that they contain attribute values 
and the equivalent type of information that may be required for 
the c omp lete solution of a probl em . A collection of fact files 
without a Knowledge Source is not a KB. A Management Information 
System constructed from a conventional da t a-manag ement system is 
not a KBS because it does not have reasoning or inferencing 
c apab i 1 i ty . 

A KS -contains what is usually called knowledge. Multiple 
KSs are usually necessary when there are multiple "levels” of 
knowledge, such as prob 1 em- spe c i f i c knowledge and knowledge 
(often called Meta-knowledge) about how the CE can best use the 
problem-specific knowledge. Since the two kinds of knowledge are 
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used for different purposes, it is reasonable to keep them in 
different KSs. It is also often true that more than one kind of 
pr ob 1 em- s pe c i f i c knowledge is acquired from different experts and 
that there is no efficient single method for representing all of 
the knowledge. Since different representations are needed, 
separation into separate KSs is logical. 

The knowledge of the KSs is usually of the following types 
[Shortliffe, 76; Davis, at.al, 77; Nau, 83]: 

(1) Methods for specifying cause-effect relationships, 

implications, or inferences, using production rules, 
predicate-calculus expressions, or other logical 
representations, depending on the richness of the 
relationship to be represented. 

(2) Plans of action for how one would achieve an end 
result in the wor 1 d external to the mode 1 that the 
system represents. For instance, such a procedure may 
describe how to transform one chemical compound into 

•"another for a chemi ca 1 -synthe s i s system, or how to 
purify an intermediate compound. 

(3) Declaratives that identify objects within the modeled 
domain and distinguish them from objects that are not 
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within the domain. These declaratives may describe 
properties of objects, relationships among objects, 
definitions of terms or constructs, schemata that 
identify the legal r e 1 a t i onsh 1 i ps or transformations 
applicable to the domain, etc. 

( 4 ) Me ta-properties , wh ich are a higher level of 
abstraction about the domain and the solution space 
and methods. They take the form of meta-rules - that 
is, rules about using the knowledge in types (l), (2), 
and (3) above. They provide a means for determining 
and assuring the consistency, coherency, and 
reliability of intermediate results and steps as well 
as the final solution and answers. They may also 
restrict the solution space in various ways (such as 
pruning and ordering a "move” tree) that markedly 
improves the effeciency of the system. 

(5) Advice (sometimes called heuristics) that is similar 
to meta-properties in intent, but that does not carry 

*~the same strength of influence. Advice may be a hint 
to the CE as to what knowledge is best to use next or 
how to escape from a possible blind alley or what is 
the most likely transformation that will yield a 
useful result. 
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There are a variety of techniques that have been used to 
represent KSs with these characteristics [Feigenbaum, 81]. They 
will be described in detail in Chapter 3. 

2.4 Cognitive Engine 

The Cognitive Engine (CE) combines and organizes the 

contents of the KB in inference or search structures in order to 
perform plausible or common-sense reasoning about the domain as 
it applies to the problem posed by the user. The intent of the 
CE is to focus the effort as narrowly as possible on the problem 
a t hand . 

The CE provides the central control of the KBS. How the CE 
does this affects both the power and the performance of the 
system, but is not the sole determinant. A KBS’s ability to solve 
a particular problem depends on: 

(1) How many paths there are to a solution. 

(2) The ability of the Cognitive Engine to reduce the 
number to a minimum. 

(3) The knowledge in the Knowledge Base. 

(4) What information is available within the problem 
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- s t a t eme n t . 

Therefore, although the Cognitive Engine is in conxnand and acts 
as the driving element, the path to a solution, and the criteria 
for when to accept a solution or abort a particular path are 
highly dependent on the content of the KB and the problem data. 

To qualify as a KBS, a system should possess the potential 
for explaining its actions and reasoning processes with respect 
to an interaction with the user or to a solution it produces. 
This is another function of the Cognitive Engine. Explanations 
are given in terms of the content of the KB, the problem data and 
prior interactions with the user and are related only to past 
activity; the system cannot explain how it might deal with a 
hypothetical case or how it will continue in solving a present 
pr ob 1 em. 

The CE must also provide the mechanisms that facilitate the 
acquisition of new knowledge, the modification of existing 
knowledge, and deleting erroneous or useless knowledge - all of 
which are - done in cooperation with an expert. A KBS does not 
generally permit its users to make permanent additions or changes 
to the Knowledge Base. 

The knowledge contained in the CE may be general or 
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me t a-knowi e dg e about how to reason (infer or search) as well as 
domain-specific problem-solving knowledge. The ultimate decision 
about what kind and what level of knowledge to incorporate in the 
CE depends on the intent of the system and the complexity of the 
domain, as well as on considerations about performance, 
efficiency, growth, and so on. 

In summary, the CE is the controlling, active element of the 
KBS that directs the problem-solving activities, explains the 
system’s behavior to its users upon request, and manages the 
Knowledge Base. 

Some of the techniques of CE are described in Chapter 3. 

2.5 Interface 

The interface is the communication port between the system 
and the external world. As such, it provides three functions: 

(1) Interaction with the user (i.e., accepting input and 
returning results, explanations, or other output often 
in English or a stylized natural language of the 
d oma in). 

(2) Addition of knowledge to the KB by a domain expert. 
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(3) * Acquisition by the KB of problem data. 

These functions are explained in more detail below: 

(1) The User Interface should acconmodate the jargon 

specific to the domain of the KBS and may permit a 
natural language. It provides the necessary 

facilities for the user as a poser of problems and a 
consumer of results (answers, explanations). It is 
not the port through which expert knowledge is entered 
into the system, nor is it intended to support casual, 
inexpert users. 

(2) The Knowledge-Acquisition (Expert) Interface is used 
by a domain expert (who has gained some feeling for 
the system) as the provider of knowledge for the KSs . 
Associated with the Knowledge-Acquisition Interface is 
some means of verifying the incoming knowledge, 
sometimes limited to syntax checking, but often 
including tests for coherence and consistency with 
prior knowledge both in the KSs and the CE 
[Shortliffe, 76]. It is possible that the KA 
Interface and the User interface use some system 
components in conxnon, but they are considered 
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" logically separate. 

(3) The Data Interface is more conventional than the other 
two. It is similar to that of most other interactive 
computer systems, in that it incorporates: 

(a) Facilities for user input of data and responses 
to the system’s queries. 

(b) The mechanism for locating and accessing files 
and data bases. 

Many of the functions necessary to provide the Data 

Interface may be drawn directly from the comput e r-sy s t em 

environment within which the KBS functions. 

Separation o f KBS El eme nt s 

The separation of the elements of a KBS is a necessary 
condition for including a system in that category, since it 
permits the changing of the domain of application by extending, 
expanding, or substituting another KB independently of the CE. 
One example: iMYCIN (for Empty MTCIN) is the CE of MSfCIN [Davis, 

et.al, 77] (also see Appendix A), to which several different KBs 
have been experimentally attached for solving different classes 
of problems. Still there is no general theory of knowledge-based 
systems complete enough to permit the facility of substituting a 
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KB from “a different domain as a means of creating a new KBS for 
that d oma i n . 

Even though it was mentioned that a KBS must have a CE or a 
KB, in most of the systems they are not so easily identifiable. 

2 . 6 Sunmary 

In surrmary, to qualify as a KBS, a system must: 

(1) Be externally invoiced by an expert in the domain of 
applicability. 

(2) Have an identifiable CE that reasons plausibly using 
the KB and whose solution path is controlled by the 
content of the KB and problem data. 

(3) Have the potential for explaining its behavior. 

(4) Have an identifiable KB that contains expert 

doma in-s e c i f i c knowledge (this is the most critical 
aspect of a KBS ) . 

(5) Be organized and structured so that its KB can be 
'"expanded and extended and the system’s performance 

improved . 
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3. TECHNIQUES USED TO CONSTRUCT KBS 

Artificial Intelligence (AI ) techniques are widely used in 
KBS. In addition to AI , several other computer science areas 
have developed techniques that are used in the construction of 
KBS. A partial list of the major contributions are sunmarized in 
Figure 3-1. 

The following subsections discuss KBS technologies grouped 
according to function. Section 3.1 describes the methods used to 
represent the knowledge contained in the Knowledge Sources (KS). 
Section 3.2 describes the methods used to model and represent the 
work-space - the dynamic state of a system during its 
problem-solving activity. Section 3.3 describes techniques that 
are used to construct the Cognitive Engine (CE). Section 3.4 
describes the techniques used to build the interface between the 
KBS and the user. 
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Table 3-1 ORIGINS OF KBS TECHNIQUES 
(Based on [Hayes-Roth, 83]) 


ARTIFICIAL INTELLIGENCE (AI ) 

Hueri Stic Search 
Inference and Deduction 
Pattern Matching 

Knowledge Representation and Acquisition 
System Organization 

LANGUAGE PROCESSING 

Parsing and Understanding 
Question and Response Generation 
Knowledge Representation and Acquisition 

THEORY OF PROGRAMMING LANGUAGES 

Formal Theory of Computational Power 
Control Structures 
Da ta Structures 
System Organization 
Pars ing 

MODELING AND SIMULATION 

Representation of Knowledge 
Control Structures 
Calculation of Approximations 

DATA BASE MANAGEMENT 

Information Retrieval 
Updat ing 

File Organization 
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3 . 1 Kn ow ledge Representation 

In contrast to conventional database systems, KB systems 
require a knowledge base with diverse kinds of knowledge 
knowledge about objects, about processes, and ha r d- t o-r epr e s ent 
comnon sense knowledge about goals, motivation, causality, time, 
actions, etc. Attempts to represent this breadth of knowledge 
raise many questions [McCalla, et.al, 83]: 

(1) IIow do we structure the explicit knowledge in a 

knowledge base? 

(2) How do we encode rules for manipulating a knowledge 
base’s explicit knowledge to infer knowledge contained 
implicitly within the knowledge base? 

(3) When do we undertake and how do we control such 

inf erence s? 

(4) How do we formally specify the semantics of a 

-'knowledge base? 

(5) How do we deal with incomplete knowledge? 

(6) How do we extract the knowledge of an expert to 
initially "stock” the knowledge base? 
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(7) ~ How do we automatically acquire new knowledge as time 
goes on so that the knowledge base can be kept 
current? 

In this section we describe some of the techniques used to 
represent such kinds of knowledge. 

3.1.1 Knowledge Representation Forms [Feigenbaum, 81] 

A knowledge source may assume several different forms of 
representation through a KBS. The domain expert imparts new 
knowledge to the knowledge acquisition mechanism in the ex t e rna 1 
form. The acquisition mechanism transforms or compiles the 
external representation into the phys i cal form and merges the new 
knowledge into the appropriate KS . The physical form is a data 
structure such as a matrix, list, or n-tuple, or a procedural 
representation, or some combination of these forms. When another 
component of the system (such as the CE) accesses the KS , the 
logical form is used at the interface. The logical form defines 
the set of questions that can be answered inxnediately by the KS . 
Finally, knowledge is transformed back into the external form 
when the system provides explanations to the user. Figure 3-2 
summarizes the transformations of knowledge representations 
throughout a KBS. 


I DffrfS .NASA/ RECON- 5 I 


32 


I KNOWLEDGE- BASED I 


I NASA I 


I N A S A 



FIGURE 3,2 KNOWLEDGE REPRESENTATION FORMS 
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There are two important t e rihs / cone ep t s in knowledge 
representation [Feigenbaum, 81]. 

Knowledge Chunks . Both the external and logical knowledge 
representation format are partially characterized by the term 
chunk size . A k n ow ledg e chunk is a primitive unit in the 
representation - that is, in a KS that contains the definitions 
of several interrelated terms, the definition of a single term is 
a "chunk”. The knowledge chunk is the unit by which the expert 
augments (or modifies) the KS . The simplest action that can be 
taken by the CE is to apply or use a single chunk. Chunk size of 
knowledge is an important consideration to KBS technology for 
three reasons : 

(1) It determines the level at which the expert can 

instruct the system. If the chunk size is either too 
large or too small, the expert is forced into an 
unnatural mode of expressing his knowledge. 

(2) It in part determines the acceptability of the 

system’s explanation mechanism. Since the knowledge 
chunks used to derive and support the system’s 

conclusions form the essential part of explanations, 
acceptability is enhanced when the chunks are the same 
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- size or level of detail used by one worker in the 

application field describing results to another worker 
in the s ame field. 

(3) It determines the kinds and efficiency of reasoning 
techniques to be used in the KBS. Larger chunk sizes 
generally permit shorter lines of reasoning. For that 
reason, they are mo re likely to lead to a correct 

conclusion wh en inexact but plausible inference 
techniques are used. 

Credibility Factors [Shortliffe, 76]. All of the knowledge 
in a KS need not be true in an axiomatic sense. Much of the 

content of a KS may be "rules of thumb” and working hypotheses. 

This raises the issue of how a system is to use knowledge of this 
sort to produce acceptable results. In many KB systems, the 
chunks in the KS are rated as to their credibility by the experts 
who entered them into the system. This rating is then available 
to the CE as a guide in the reasoning process. 

Thero~are at least four possible meanings or interpretations 
of credibility factors: 

(1) A probability: the fraction of the time the chunk is 
true. 
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(2) - Strength of belief: how certain is the expert that the 

chunk is always true? 

(3) Acceptability: is this a preferred method or fact to 

workers in the field? 

(4) Relevence: wh at is the probability that use of this 
chunk will ultimalely lead to a completed chain of 
reasoning that solves the problem at hand? 

It is essential that the kind of credibility factor that is 
to be used be stated and agreed upon by the expert who instructs 
the system and by the programmer who builds the CE . 

Additional references include the following: [Tversky, 72; 

Zadeh 7Sa; Zadeh 75b; Goguen, 68]. 

3.1.2 Methods of Representing KS [Feigengaum, 81] 

Some of the methods of representing a knowledge source: 

(1) --Finite-state machine. 

( 2 ) Programs . 

(3) Predicate calculus. 
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(4) - Production rules. 

( 5 ) S ema n t i c n e two r k s . 

( 6 ) F r ame s . 

(7) Conditional probabilities. 

In this report I will describe only production rules, 
semantic networks and frames. The other methods will be 
discussed in a subsequent report. 

3.1.3 Production Rules [Feigenbaum, 81] 

Production rules have been used as the principal method of 
representing knowledge in many (if not most) of the highly 
successful KB systems - for example, MYCIN and DENDRAL. 

A pr oduc t i on rule is a specification of a conditional 

action. It consists of a left hand side (LHS), also called the 
condition or the antecedent, which describes a situation, and a 
r i ght hand side (RHS), also called the action or consequence, 
which describes something that may legally be done in a situation 
described by the LHS. 

For example, in ”If you are outdoors and it is raining, then 
open an umbrella”. The conditions are ’being outdoors’ and 
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’rain’. The action is to open an umbrella. 

Production syst em is a three-component entity: 

(1) A collection of production rules. 

(2) A wo r k s p a c e . 

(3) A control mechanism. 

The production rules are represented by some agreed-upon 
syntax, by means of which the LHS and RHS are built up from a set 
of primitives and symbols that correspond to objects, functions, 
and predicates in a domain. The workspace contains the total 
description of the system’s current state or situation. The LHS 
of a rule describes, or is matched against, the contents of the 
workspace. If a production is applied, i.e., its LHS matches and 
its RHS is executed, then the RHS act ions mo d i f y the wo r k s p a c e . 

The control mechanism has two parts. The first part builds 
the conf 1 i c t set - the set of all production rules whose LHSs are 
satisfied.- - If the conflict set is empty, then processing is 
terminated, and the result is the contents of the workspace. 
However, if the conflict set is not empty, then the 
confli ct-resolution strategy selects one member of the conflict 
set and the RHS of the selected production rule is executed. 
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Several 'conflict-resolution strategies have been used or 
proposed. 

Kulfc order - There is a complete ordering of all production 
rules. The rule in the conflict set that is highest in the 
ordering is chosen. 

&W.1.S- precedence - A precedence network determines an 
ordering . 

Ge nerali ty order - The most specific rule is chosen. 

BaXa. o rder - El erne nts of the wo rkspace are ordered. Th e 
rule chosen is the one whose LHS references the highest-ranking 
workspace element(s). 

JBeg-£jtlcy order - Execute the rule in the conflict set that 
was most (least) recently executed, or the rule in the conflict 
set whose LHS references the most (least) recently referenced 
e 1 erne n t ( s ) . 

Non-de t e rmi ni stic - Execute every rule in the conflict set 
as if it'were the only member. Computation stops when any path 
terminates . 
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3.1.4 An -Ex amp 1 e 

The example is a production system that assists the service 
manager and mechanics in an automobile repair agency (refer back 
to Section 2.1). The scenario for using this system is the 
arrival of a customer at the agency. He reports the symptoms and 
problems to the service representative, who then enters this 
information into the system. The system has at its disposal a 
data base of past problems, repairs and services performed on the 
vehicle, and a KS of production rules that describe 
cause-and -effect relationships among the performance 
characteristics and measurable attributes of an automobile. 
Using the reported information, the past-history data base, and 
the KS , a diagnostic and repair plan is formulated and 
imp 1 ement ed . 

Figure 3-3 gives a few of the production rules that might 
be present in such a system. Each rule is named; however, the 
rule names are used only for convenience. The format of the rule 
i s : 


IF lhsl Cl lhs2 .... Cn-1 lhsn 

THEN rhsl[pl] K1 rhs2[p2] .... Kin-1 rhsm[pm] 
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R1 IF fan belt tension is low 

THEN alternator output will be low [.5] and engine will 
overheat [ . 2] 

R2 IF alternator output is low 

THEN battery charge will be low [.7] 

R3 IF battery is low 

THEN car will be difficult to start [.5] 

R4 IF automatic choke malfunctions OR automatic choke 
needs adjustment 

THEN car will be difficult to start [.8] 

R5 IF battery is out of warranty 

THEN battery charge may be low [.9] 

R6 IF coolant is lost OR coolant system pressure cannot be 
ma i n t a i n e d 

THEN engine will overheat [.7] 

R7 IF there is a high resistance short AND fuse is not 
b 1 own 

THEN battery charge will be low [.8] 

R8 IF battery fluid is low 

THEN battery will boil off fluid [.3] 

R9 IF battery fluid is low 

THEN battery charge will be low [.4] 


Figure 3-3 PRODUCTION RULES FOR AUTOMOTIVE SYSTEM KS 
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where the Cl and K1 are the connectives AND or OR. The LHS is 
evertything between the keyworkds IF and THEN, and the RHS is 
everything following the THEN. Each lhs(i) is an observable or 
measurable condition predicate, e.g., that the tension of the fan 
belt is low or the engine is overheating. Each rhs(i)[p(i)] is a 
condition, rhs(i), that will follow with certainty or 
probability, p(i). Thus rule R1 says that, if the tension of the 
fan belt is low, then there are two possible consequences: 

(1) That about one-half of the time the output of the 
alternator will be low. 

(2) About one-fifth of the time the engine will overheat. 

The other production rules, R2-R9 , are interpreted in a 
similar manner. 

A fact file in the system is shown in Figure 3-4. The 
information included for each observation or measure is the agent 
from whom to gather data and the relative difficulty (or cost) of 
gather ing -the data. 
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OBSERVATIONS 

AGENT 

DIFFICULTY 

Alternate Output Level 

Mech 

4 

Battery Charge Level 

Mech 

3 

Battery Fluid Level 

SrvR 

2 

Choke Adjustment 

Mech 

5 

Choke Function 

Mech 

5 

Coo 1 ant Leve 1 

SrvR 

2 

Coolant System Pressure 

Mech 

5 

Difficulty to Start 

Cu s t 

1 

Engine Temperature 

Cu s t 

1 

Fan Belt Tension 

Mech 

3 

Fuse Condition 

SrvR 

2 

Short in Electric System 

Mech 

8 

Voltage Regulator Level 

Mech 

4 

Wa rranties 

Data Base 

0 


Figure 3-4 DATA GATHERING PROCEDURE FACT FILE 
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There 

are four possible agents 

for data 

gathering: 

(1) 

The customer (Cust). 



(2) 

The historical data base 



(3) 

Inspection by the service 

manage r 

(SrvR) . 

(4) 

Measurement by the mechanic (Mech) 

• 

The 

difficulty info rma t i o n 

wi 11 be 

c omb i n e d 


confidence factors in the production rules to formulate the most 
cost-effective and timely plan for the needed diagnostics and 
repairs . 


Assume that a customer arrives at the agency with the vague 
complaint that his car is hard to start. The service manager 
enters this information, including appropriate customer and 
vehicle identification. The system then grows a structure 
similar to that shown in Figure 3-5. The boxes are labeled with 
observable or measurable symptoms and are connected by arrows 
labeled with the names of the production rule they represent. To 
the far right of each of the unknown values (e.g., the box 
labels, such as battery-fluid level), the associated agent and 
relative difficulty are listed. At this point, the system would 
check the data base for information about the battery’s warranty. 
If nothing decisive was found, then the customer would be asked 
whether the car was running hot, and the service manager would 
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continue To make on-the-spot observations. Diagnostic procedures 
for causes not ruled out by the procedure to date would then be 
placed on an ordered schedule for a mechanic. 

The ordering would be based upon: 

(1) Cost effectiveness - a function of test difficulty, 
estimated probability of being necessary, and ability 
to eliminate other tests. 

(2) Availability of resources - speciality mechanism and 
test equ i pment . 
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The "structure shown in Figure 3-5 was grown by an algorithm 
called back cha ining . A condition - in this case, "difficult to 
start” - is taken as a given, and the goal of the system is to 
find the cause(s). Note that the production rules state causes, 
then effects. Thus, the rules are used as if the knowledge 
possessed a kind of symnetry. The ba ck-cha i n i ng algorithm is: 

(1) Find all rules that have the initial or derived 
condition as their consequence (in this case R3 and 
R4 ) . 

(2) Call the antecedents (LHSs) of these rules’ derived 
conditions. 

(3) Repeat steps (l) and (2), and terminate when no more 
can be done . 

Figure 3-6 graphically shows the kind of structure grown 
for each kind of rule format. In each example in the figure, cl 
is the initial or a derived condition. 

Rule El is the simplest; al is added to the set of derived 
conditions. Rule E2 states that if al is the case, then both cl 
and c2 ought to follow. Thus, al is a derived condition, and c2 
may or may not be considered a derived condition, depending upon 
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the par f i cu 1 a r 

s trategy used 

by the 

sy s t em. 

Rule 

E3 

i s 

equivalent to two 

independent rules ”IF 

a 1 

THEN Cl” 

and 

"IF 

a 1 

THEN c 2 ” . Th erefore, al is 

added 

to 

the set 

of 

derived 


conditions, and c2 part is ignored. 

The example and discussion is some what simplistic, because 
there might be some problems which we did not consider. For 
example, suppose that rule R8 (in Figure 3-3) had been written 
more accurately as the two rules: 

R8(l) IF voltage regulator output is high 
THEN the battery will overcharge. 

R8(2) IF battery is overcharged 

THEN battery will boil off fluid. 
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~ El IF A1 THEN Cl 


E2 IF A1 THEN Cl AND C2 


E3 IF A1 THEN Cl OR C2 




FIGURE 3.6 BACK CHAINING 
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With - these new rules, a fragment of the structure shown in 
Figure 3-5 would be replaced by that shown in Figure 3-7. Now, 
the interesting conclusion is that a high battery charge implies 
a low battery charge. This is an apparent contradiction, since 
both conditions cannot hold at the same time. This kind of 
situation can often arise in unpredicted ways if the system 
contains many rules - more than a few dozen. The charge of the 
battery will oscillate between high and low as the battery fluid 
is replaced and boils off, respectively. So, in a sense, there 
is a missing rule of the form that adding fluid to a battery 
whose charge and fluid levels are low will probably allow the 
battery to return to normal conditions. However, to handle this 
kind of situation in general, it is necessary that the control 
mechanism or CE have some knowledge about how to proceed when 
faced with apparent conflicts and contradictions. One virtue of 
production systems is that ad hoc knowledge may be relatively 
easily incorporated in the system to handle this. 

Additional relevant references include the following: 
[Davis, et.al, 77; Shortliffe, 76; Shortliffe 75; Buchanan, 76; 
Feigenbaum, 71; Barnett, 75; Collins, 76; Forgy, 76]. 
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3.1.5 Semantic Networks [Nau, 83; Feigenbaum, 81] 

A semantic network is a method of representing declarative 
knowledge about the relations among entities. The major 
application has been to include non-syntactic knowledge (e.g., 
semantics) in na t u r a 1 - 1 anguag e understanding systems. Because of 
their inherent generality and naturalness, semantic network have 
been used to represent highly interrelated information that 
cannot be properly processed by standard data base management 
t e chn i que s . 

A semantic network is a KS . It is built up from knowledge 
chunks that are instances of a relation. The format of a chunk 
is: rel (al ... an), where rel is a relation name and the ordered 
tuple, (al ... an), is in the relation rel. For example, ISA 
(Dog, Mamna 1 ) means (Dog, Maxima 1 ) is a member of the relation 
ISA. ISA is conventionally taken to be the relation, 
mor e-spe c i f i c-exmap 1 e-of . Thus, the above is the representation 
of the fact that a Dog is a specific kind of Maximal. 
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RELATIONS 

TEMP (WARM-BLOODED MAMMAL) 

isa(dog, mammal) ISA (cat, mammal) 
isa(fido,dog) isa(bowser,dog) isa(puff,cat) 
loc(mary's,fido) loc(firehouse, bowser) loc(bob's,puff) 
color(tan,fido) color(tan, bowser) color(black,puff) 
size(40lb,fido) size(14lb, bowser) size(4lb,puff) 
between (mary's, firehouse, bob's) 


SEMANTIC NETWORK 

MAMMAL 



RULES OF INFERENCE 

isa(x,y) a isa(y,z) => isa(x,z) 

SIZE(x,Y) a SIZE(u,V) a X<U = > SMALLER (Y, V) 

isa(x,y) a r (u,y) => r ( u,x) 

FIGURE 3.8 EXAMPLE SEMANTIC NETWORK 
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Figure 3-8 shows a semantic network (or net). The top of 
the figure lists the instances of relations using the relation 
names TEMP, LOC , COLOR, SIZE, ISA, and BETWEEN. TEMP( a , b ) means 
a is the t emp erature of b; LOC (a,b) means a is located at b; 
COLOR(a.b) means that a is the color of b; and SIZE(a,b) means a 
is the size of b. The knowledge in a semantic net is given 
meaning by defining the relation names and other symbols used in 
the instances of relations, in terms of external entities. 

The graph in the middle of Figure 3-8 shows exactly the 
same knowledge that is in the set of instances at the top of the 
figure. The entity names are connected by arrows labeled with 
appropriate relation names. 

The external format of knowledge in a semantic network is 
usually very similar to the one used here. However, the internal 
storage of the semantic network closely corresponds to the 
graphical presentation - that is, a network structure built using 
pointers and list structures. The explicit connections among the 
entities enhances efficiency of programs that search through the 
semantic network. 

The bottom of Figure 3-8 gives some examples of inference 
rules for the semantic network. It is possible to represent the 
inference rules as a production system. This has the advantage 
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of allowing procedural knowledge to be used to test for complex 
c ond i t i on s . 

The first rule says that (for all x, y, and z) if x is a y 
and y is a z, then x is also a z. An example of this is: Fido is 
a Dog and a Dog is a Maixma 1 ; therefore, Fido is a Maxima 1 . The 
second rule says that if y and v are two entities that have SIZE, 
and the size of y is less than the size of v, then y is SMALLER 
than v. Thus the instance of the relation, SMALLER ( Puf f , 
Bows e r ) . 

This inference rule defines instances of relations whose 
names do not appear explicitly in the semantic network. The last 
example inference rule says that, if x is a y, and y has a 
property conferred by the binary relation, r, then x has the same 
property conferred by r, i.e., properties are inherited. Thus, 
Fido is a Maximal (by the transitivity of ISA - first rule), and a 
Maximal has the property, WARM-BLOODED (conferred by the relation 
TEMP), therefore, Fido is WARM-BLOODED. 

However, the indiscriminate use of the third rule can cause 
derivation of incorrect results. For example, 

ISA(Dog, Maximal) AND ISA(Cat, Maximal) ISA(Dog, Cat) 
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In order to avoid this kind of problem, it is necessary to 
have some knowledge ( non- synt a c t i c ) about the relations to which 
inference rules are applied. One possible solution is to have a 
rule, such as the third example rule, for each relation that is 
inheritable. Another solution is to embed the inference rules in 
the CE along with the necessary ad hoc knowledge to avoid the 
problems. If the number of relations occurring in the semantic 
network is large or if the relation set can be modified or 
expanded - then both these approaches cause problems. 

A more general approach to the problem treats relation names 
and entity names more uniformly. For example, temperature is 
defined as an inheritable property by an instance like 
INHERITABLE (TEMP) . 

The third inference rule is then rewritten as: 

I SA( x , y ) AND r(u,y) AND I NHER I TABLE ( r ) — > r(u,x) 

With this approach, relations can be arguments to relations, 
and hence -fiave the same properties as other entities. 

Another choice and tradeoff about a semantic network is the 
decision about whi ch relations and which instances in the 
relations ought to be stored explicitly and which should be 
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computed via the inference rules. Explicit storage costs space, 
and inference rules cost computation time. 

A technique often used with semantic networks is to make a 
distinction between general knowledge and specific knowledge and 
to store the two in a different manner. Specific knowledge has 
the general characteristic of being ” 1 ow” in the tree - as shown 
in the middle of the figure. This means: 

(1) There are few if any chains below it. 

(2) Therefore, properties have simple values. 

(3) Most entities in the same general classification have 
all and only a known set of properties. 

( 4 ) Th ere are a large n umb er of entites in a general 
class. For our example, the specific knowledge can be 
displayed tabularly as: 



ENTITY 

ISA 

SIZE 

COLOR 

LOC 


Fi do 

Dog 

4011b 

Tan 

Mary * s 


Bowser 

Dog 

1411b 

Tan 

F i rehouse 


Puff 

Ca t 

411b 

Black 

Bob’s 

The 

above conditions 

make i t 

likely 

that the specific 

knowl edge 

can be 

gathered 

into a 

tabular 

form by s imp 1 e 
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mechanicah means, and that the specific knowledge (which is 
usually most of the semantic net) can be kept in relatively 
inexpensive secondary storage and even accessed through an 
efficient, existing data management system. The general 
knowledge is kept in primary memory. Fortunately, most 
processing by the inference rules occurs on other than the 
"bottom” of the network, so that efficiency is maintained. 

Semantic networks are by far the best available technology 
for representing definitional and relational knowledge that is 
too complex for ordinary data management techniques. This is the 
case because the structure allows for the inclusion of ad hoc 
information, and the utilization of inference rules permits 
straightforward enhancement of the inherent representational 
power and completeness. 

On the other hand, there are some disadvantages to the use 
of semantic networks to represent knowledge in a KBS. The 
principal one is that the chunk size is fairly small. The result 
of this is that reasoning chains can be quite lengthy and 
tedious. -“Another result is that processing a semantic net can 
consume large amount of computer time. 

Additional references include the following: [Duda, et.al, 
77; Grignetti, 75; N^ylopaulos, et.al, 75; Norman, 75; Woods, 75; 
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Schubert , -76 ] . 

3.1.6 F r ame s 

A research topic of great current interest in c omp u t e r 
representation of knowledge is frame theory. No one has succeded 
in defining frames to all researchers’ satisfaction. Some of the 
c ommo n features in proposals about fr ame s are: 

(1) A frame is a knowledge chunk. 

(2) A frame has a collection of definitional and procedural 

knowledge about an object, action, or concept. 

( 3 ) A f r ame i s a c omp lex data structure that has n ame d slots 

corresponding to definitional characteristics. 

( 4 ) A f r ame has the ability to attach procedural kn ow ledge 

to the slots and/or to the frame itself. 

An example (Figure 3-9) to illustrate some of the above features 
is discussed bel o w . 

The top of the figure presents definitional information 
about a -dog. The first line states that a dog is a "mamma 1 ” . 

The next line means that there is a slot, named "kind” (of dog), 
that may be filled with a value of (type) "breed”. ("Breed” in 
this example is itself a frame). The color of a dog is limited 
to one or a mixture of the stated colors by the SUBSET. OF 
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operator.- Default values are indicated by underlining, and the 
FRCM operator is used to pick out values from other frames. 
Thus, the combined effect of the phrase FRCM color OF kind is 
t o ma ke the default value for the color of a dog the default for 
his breed. The state of a dog is either "adult”, the default, or 
"puppy” if the age is known to be less than one year. 

The bottom of the figure shows a frame for "boxer” and 
declares that boxer is a breed - but only a breed of dog. The 
color of a boxer is restricted to one of the colors "tan", 
"brown”, and "brindle”, with a default of "tan”. If this breed 
did not have a characteristic color restriction, then this slot 
would be omitted. The next slot says that the size of a boxer is 
between 40 and 60 pounds. No default is specified. The tail and 
ears slots are defined with default value "bobbed” and the 
respective alternatives of "long” and "floppy”. 
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dog 
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Figure 3-9 EXAMPLE FRAME DEFINITIONS 
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-Temperment is shown to always be playful. The last 
line shows an example of a complaint and ad hoc knowledge 
used to make a recommendation, namely, if you see a giant 
boxer, then assume that it might be a Great Dane instead. 

Figure 3-10 shows an example use of frames in a 
recognition task. The top of the figure shows some feature 
values (e.g., color is tan, ears are bobbed) that have been 
detected for an object, here identified as number 456. The 
CE has matched the known feature values with the available 
frames and has manufactured the working hypothesis shown at 
the bottom of the figure - namely, a boxer dog that is 
assumed to have bobbed tail and to be an adult. It is noted 
that this particular boxer (object number 456) is mean and 
that this is exceptional. Also, the size of the boxer was 
only approximately known, but the approximation has been 
used in lieu of a more accurate value. 
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Figure 3-10 INEXACT MATCH BY A FRAME 


tan 

40 - 45 

ASSUMED bobbed 
bobbed 
EXCEPTIONAL 
me an ] 


SYSTEM 


I DIMS . NASA/ RECON- 5 I 


63 


I KNOWLEDGE-BASED I 


I NASA I 


I N A S A I 


“A possible scenario for the recognition task: A 
general matching procedure would attempt to instantiate all 
frames in the system until a reasonable fit was found; in 
the example, "boxer” is a reasonable match. Slots that are 
yet unfilled would be used to hypothesize other values not 
yet detected. For the boxer frame, a bobbed tail would be 
predicted and put on an agenda of things to look for. 
Assuming there was a frame for tails, it might possibly 
contain heuristic knowledge about how to more carefully scan 
the raw data to confirm or deny the existence of a 
particular kind of tail. Other activity that could emanate 
from the boxer frame is the activation of a complaint. 
Thus, if the weight of the boxer was too large, the 
complaint mechanism could change the identification of the 
instantiation of the boxer frame into one for a Great Dane. 

Besides the prediction and correction activity 
resulting from the partial match to a frame, a third process 
can be tried. Namely if the match is good enough, then the 
frame can become more informative. For our example, the 
transf ormaton is from a boxer to a boxer dog where more 
information is absorbed, e.g., leggedness. 

The belief is that this style of recognition will be 
more goal directed - and hence more accurate and efficient - 
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than-general techniques that depend upon regularity and 
uniformity of structure. 

Additional relevant references include the following: 
[Nilsson, 80; Winston, 77; Bobrow, 77; Winograd, 75; 

Malhotra, 75; Davis, 76]. 

3 . 2 Wo rkspace Representation 

The workspace is the encapsulation of the system’s 
current state in a problem solving activity. It includes: 

(1) Global variables - computed values, goals, and input 
problem parameters. 

(2) An agenda - a list of activities that can be done 
next . 

(3) A history - what has been done (and why) to bring the 
s y s t em to its current state. 

The -simplest example of a workspace representation is the 
push-down stack in a LISP-like system. The stack contains the 
bindings of global variables, return address (a history 
snapshot), and the values of temporaries. There is no agenda in 
a simple system other than the program counter. A more 
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complicated example is the data base in a production system. It 
contains the entire state of the system, including an implicit 
agenda (the conflict set of rules that can apply). 

I n mo st c omp uter progr ams , the wo rkspace can be represented 
in an ad hoc way using whatever techniques are provided by the 
containing proram- 1 anguage system. However, this is not always 
adequate in KB system because: 

(1) The capability to provide explanations is based in 
part on an ability to find the trace of events 
(history) that produced the solution. 

(2) Efficient reasoning behavior depends on the selection 
of the next thing to be done - hence, the necessity 
for an explicit agenda and visibility of enough state 
(global variables) to make informed decisions. 
Further, if a KBS has many knowledge sources, the 
workspace representation may be used to provide a 
conxnunicat ion channel among them. 

3.3 Cognitive Engine 

In a KBS, the primary function of the cognitive engine (CE) 
is to perform the task of problem solving. A secondary function 
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of the CE~ i s to explain the behavior of the system and support 
its derived solutions. To accomplish these functions, the CE 
mu s t : 

(1) Control and coordinate system activities and 

re source s . 

(2) Plausibly reason about doma i n- s pe c i f i c problems by 

having access to and using the contents of the KB, the 
contents of the workspace, and knowledge and 

procedures embedded in the CE . 

(3) Link the KB with the interface module(s). 

The CE is the most active component of a KBS. That is, it 
is always instantiated, and it controls the activation and 
utilization of other sy s t em modu 1 e s . Another characterization of 
a CE is that it is the intelligence or understanding component of 
a KBS (even though its activity may, to a degree, be guided by 
higher-level (control and/or meta) knowledge in a KS) . 

The following three definitions are from [Feigenbaum, 81]. 

A CE is sound if it produces only correct or ”1 don’t know” 
solutions, i.e., it does not produce incorrect solutions. 
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A CE“is c nmp 1 e t e if it can always produce a solution to a 
posed problem when a solution exists. 

A CE is admi s s i b 1 e if it always finds a minimal-cost 

solution when a solution exists. The cost is taken to mean the 
cost of using the solution, not necessarily the cost of finding 
i t . 

3.3.1 CE Strategies 

The input to a CE is usually a set of initial conditions and 
a goal. The KB is used in some manner to find a method of 

obtaining the goal given the constraints imposed by the initial 

conditions. There are four ways of doing this: 

(1) Forward chaining - apply the KB to the givens to infer 
new conditions; continue in this manner until the goal 
is satisfied. 

(2) Back chaining - apply the KB to the goal to produce 

new subgoal s : continue in this manner until the 

initial constraints or primitive conditions (known to 
be solvable) are reached. 

(3) Chain both ways - forward chain from the initial 
conditions and backward chain from the goal until a 
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- conmon middle term is produced. 

(4) Middle term chaining - using the KB, guess a middle 
term and solve separately the problem of getting from 
the initial conditions to the middle term and from the 
middle term to the original goal; continue in this 
manner until a solution in terms of primitives is 
generated. (This method is also called p r o b 1 em 
.red u c t ion . ) 

Figure 3-11 shows an example of the first three of these 
techniques. The KB contains three rules: 

(1) Any integer, x, can be replaced by 2x (x --> 2x). 

(2) Any even integer, 2x, can be replaced by x (2x --> x). 

(3) Any integer, x can be replaced by 3x+l (x — > 3x + 1). 

The problem is to transfer 4 into 20 using the permitted 
operations. The top figure shows forward chainging - i.e., start 
with 4 and apply the operations until 20 is produced. The middle 
figure shows back chaining - i.e., start with the goal, 20, and 
use the inverse of the above rules and continue until 4 is 
produced. The bottom figure shows the chain-both-ways technique. 
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First, one step of back chaining produces the nodes labeled 10 
and 40. Then one step of forward chaining produces the nodes 
labeled 8,2, and 13. Finally, one more step of back chaining is 
done to produce the nodes labeled 5,3,13, and 80. Since 13 is on 
both the forward and backward grown "wave fronts”, the process 
can terminate; otherwise, the steps of forward and backward 
chaining would continue to alternate until either a solution was 
found or the system gave up. 
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Another way of differentiating CE strategies is via 
breadth-f irst vs . depth-f irst . In a breadth-first system, all 
possible methods of continuing are attempted in parallel. This 
is showed in Figure 3-11, where each (horizontal) level of the 
graph was generated by a single cycle of the system. In a 
depth-first system, some path (node, state, etc.) is selected and 
a single continuaton is attempted, i.e., the node is not fully 
expanded all at once. This path continues growing until either 
the path reaches a solution or some path-length constraint is 
violated. In the latter case, the path is backed up to the 
deepest node at whi ch an alternative exansion exists. At that 
point, another path continuation is generated. This process 
continues until either a solution is produced or the alternatives 
that could produce a solution within the length constraint are 
exhausted. A depth-first strategy can be more efficient than a 
breadth-first one if a good technique exists for ordering 
production of path extensions. Figure 3-12 shows an example of 
a depth-first strategy combined with back-chaining for the prior 
problem. A maximum path length 4 was used as a constraint, and 
the order -<jf (inverse) operator application was: 

( 1 ) n -- > 2n . 

( 2 ) 2n — > n . 
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(3) “ n — > 3n+ 1. 

Each node has a superscript that denotes the order in which 
the nodes were generated. 

Additional references include the following: [Nilsson, 80; 

Klahr, 78; Miller, 73] . 
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FIGURE 3.12 DEPTH-FIRST BACK CHAINING 
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3.3.2 Methods of Implementing the CE 

Most methods and techniques used to implement a CE are 
intimately connected to the choice of a representation technique 
for the KB. However, there are a few methods that are general 
enough to be used with a variety of KB representations. Two 
classes of them are: search methods and mode 1 ing/ s imul a t on 

methods [Feigenbaum, 81]. The third widely used technique is 
pattern-matching [Kanal, 68]. 

These techniques will be addressed in a future report. 

3.4 The Interface 

The interface component of a KBS provides the necessary 
connections and comnuni cat ions with the environment and user. 
It is not always engineered as a separate module in the system; 
usually it is integrated into the CE and accesses the KB [Davis, 
76] . 

The interface has three logical parts: the user interface, 
the expert interface, and the external data interface. 
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3.4.1 The User Interface 

The user interface is the most important component of a KBS 
in determining its acceptability to the practitioners of the 
intended domain. In general, they are neither computer scientists 
nor programmers, and may view the computer, especially a KBS, as 
a feared and unworthy competitor. A properly functioning user 
interface will smooth out and minimize the problems associated 
with learning any new system, and in the long run improve system 
productivity by making it possible for the users to be more 
cooperative in problem-solving activities. 

In order to qualify as a KBS, the user interface must, at a 
minimum, be interactive and use doma in- spec i f i c jargon. The 
reason for requiring the system to be interactive is simply that 
the state of the art does not provide techniques for going from 
problem statement to "best” answer without additional information 
that must be solicited from the user. The problem with providing 
initially, along with the problem statement, all information that 
might conceivably be needed, is that most of it is unnecessary. 
Another re-arson for wanting a KBS to be interactive is so that 
explanations of system behavior and results can be solicited. 

Besides using domain-specific jargon, many KB systems accept 
and output information using an English-like natural language. 
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Much of the ambiguity of natural language can be eliminated when 
the dialog is restricted to a particular domain and it is known 
that the user is engaged in goa 1 -o r i en t ed problem-solving 
activity. 

Another desirable characteristic of the user interface is 
soft failure. That is a KBS should not blow up because the user 
makes a mistake, nor should it conceal its problem. A useful 
technique to smooth over some problems of this sort is a spelling 
corrector . 

One of the problems confronting the explanation mechanism in 
the user interface is translating explanations into a natural 
form for the user. Fortunately, the complexity of this task is 
substantially reduced by uniformities of format in the KB and in 
the workspace. For example, in a production system, it is 
straightforward to turn an IF-THEN rule out in reasonable 
English. The usual approach is to have a separate scheme for 
each kind of knowledge chunk in the KB and element in the 
workspace; most such schemes look like sophisticated 
f i 1 1 - in- tlre-b 1 ank formulae. 

3.4.2 The Expert Interface and Knowledge Acquisition 

The expert interface is the mechanism through which 
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knowledge is added to the KB or the KB is modified. Its intended 
users are experts in the problem domain and the system 
implementors who are responsible for building the initial KB. 
This interface is often called a knowledge acquisition interface 
[Barnett, 75]. Unlike the user interface, it can be assumed that 
the user of the expert interface has some knowledge and awareness 
of the structure and functioning of the KBS. Table 3-1 
summarizes the knowledge-acquisition process. 

The knowledge that goes into a KBS must originate from some 
external source. The most usual is an expert in the problem 
domain. He can provide specific facts, rules of thumb, and the 
rules of reasoning, along with his rating of confidence. Other 
originating sources of knowledge commonly used are journal 
articles, texts and engineering handbooks. The information from 
these sources often is hard data and tabular. Therefore, it 
usually c omp rises fact files in the KB . 
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ORIGINATING SOURCE 

Doma in Expert (or User) 

Journa 1 s 
Texts 

Protocol Studies 
Der ived Results 

ENTERED BY 

Doma in Expert 
Imp 1 erne n t o r 
User 
CE 

COMPILED BY 

Knowledge Acquisition Interface 
Impl ementor 

ISSUES 

Interface Language 
Cons i s t ency 
Ac c ommo d a t i o n 
Confidence Factors 

MAJOR OUTSTANDING PROBLEMS 

Knowledge Acquisition 

Learning 

Ext ens i b i 1 i ty 


TABLE 3-1 KNOWLEDGE ACQUISITION 
(Based on [Hayes-Roth, 83]) 
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“Ideally, the knowl edg e-acqu i s i t i on interface can be 
used by domain experts and users of the system other than 
the implementation staff. However, in many KB systems, the 
complexities of adding to or modifying the KB are such that 
progranming skills are required. For such systems, a 
computer specialist may need to act as an intermediary 
between the originating source and the KBS. 

The knowledge-acquisition interface has three major 
tasks : 

(1) Accepting knowledge in external format and translating 
it into internal fo rma t . 

(2) Validating consistency of new and old knowledge. 

(3) Storing knowledge into the KB. This is called 
Comp i 1 a t i on . 

4. APPLICATION CONSIDERATIONS [Buchanan, 75; Nilsson, 80] 

Though there exists a relatively diverse collection of 
existing and developing KBS applications, the selection process 
for each new application requires consideration of a variety of 
issues. First, there is a set of initial considerations that 
address the issues of the problem domain itself and the people 
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associated with it, the experts and the practitioners. Next, are 
the technology considerations that focus on the availability of 
usable technology for implementing a KBS that has successfully 
met the first criterion. Last, there are the equally important 
considerations that are directed at determining whether or not 
the development environment and the user environment are properly 
support i ve . 

Each of these groups is considered below in the form of a 
set of questions [Buchanan, 75]. 


4.1 Initial Considerations 

(1) Does the problem have a closed-form solution? 

(2) Is there an expert who knows how to solve problem? 

(3) Is there an expert available and can he work on the 

development of a KBS? 

(4) Does the expert have a model to solve the problem? 

(5) Is the domain well bounded? 

(6) Are the intended users professionals? 

(7) Are the economics right? 
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4.2 Technology Considerations 

(1) Can a first-order model (simulation) be constructed 
with the help of expert(s)? 

(2) Is there a knowledge representation that matches the 
"chunk size” of the expert’s knowledge? 

(3) What are the necessary knowledge source(s) and their 
representation(s)? 

(4) What reasoning or inference methods are needed? 

(5) Are the knowledge representation and reasoning method 
c omp atible with one another? 

(6) Will the system support growth? 

4.3 Environmental Considerations 

(1) Is there an interactive system for the KBS users? 

(2) Do the necessary tools exist, in particular a properly 
expressive progranming system? 

(3) Will the resultant system perform effeclently? 
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5. CONCLUSIONS 


The technology of knowledge-based systems has emerged from 
the laboratory, but it has not achieved the status of being a 
commonly known way of implementing computer-based application 
systems. Systems have been developed in an intriguing spectrum 
of application areas, from medicine and chemistry to geology and 
business. The general level of accomplishment appears to be high 
enough to make it worthwhile to begin exploring other areas for 
immediate potential application. 

There remain a number of unresolved issues. Even with a 
group of domain experts who are cooperative and well motivated, 
the methodology for transferring their knowledge to the system 
is, at best, ad hoc. This is the area in which more research is 
needed to discover (or convert) what amounts to a completely new 
technology: the acquisition, comnuni ca t i on , and representation of 
expertise (the ability to use a body of knowledge effectively in 
solving a "particular problem). 
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APPENDIX A. A KBS CASE STUDY (MTCIN) 

M¥CIN is a medical consultation system. The material 
covered here is a condensation of [Shortliffe 76; Shortliffe 75; 
Davis, 77; Davis, 76]. 

Thfe- Pro bl em Domain. And. The Users 

MYCIN is a knowl e dg e - ba s ed interactive computer system 
intended to provide advice to physicians on prescribing 
antimicrobial therapy for bacterial infections of the blood 
(bacteremia). The problem of therapy selection and 
recomnendat ion for an infectious disease is difficult and 
complex. The first is to determine whether or not the infection 
is serious enough to warrant treatment. If it is determined that 
treatment is warranted, one should know what organism is causing 
the infectious disease. To do this, one must obtain a specimen 
of the infection for culturing, analysis, and identification by a 
laboratory. This is a time consuming process. And in many 
cases, the infection is serious enough that treatment must be 
begun before all of the analysis can be completed. Therefore, 
any recommended therapy must be based on incomplete information. 
To further complicate matters, the most effective drug against 
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the suspected or identified organism may be totally inappropriate 
for the specific patient because of age or medical conditions and 
problems. Thus, any system or consulting physician must be aware 
of all of these complexties if proper advice is to be rendered in 
each specific case. MYCIN has been designed to cope with just 
such complexities and interrelationships among the many variables 
and to provide a physician with advice that is proper for each 
individual patient. 

Th ough the probl em is quite c omp lex, the d oma in is we 1 1 
bounded. MYCIN requires knowledge related only to infectious 
diseases, and knowledge related to experience with various 
infectious organisms in terms of resistance to specific drugs, 
and knowledge of symptoms related to specific infections. 

MYCIN is intended to be used by physicians. The dialogue 
that it carries on with the user is in the jargon of medicine and 
specifically that of infectious diseases, laboratory procedures, 
infectious organisms, drugs, etc. Thus, a user is expected to be 
a competent medical practitioner. 

MUCIN’S Knowledge Base 

MYCIN’s knowledge base (KB) contains several knowledge 
sources - production rules, clinical parameters, special 
functions, and procedures for therapy selection. 
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Each production rule consists of a Premise, which may be a 
condition or a conjunction of conditions, an Action to be taken, 
and sometimes an Else clause. For the action to be taken, each 
of the conditions in the Premise must hold. If the truth of the 
Premise cannot be ascertained or the Premise is false, the action 
in the Else clause is taken if one exists; otherwise, the rule is 
ignored. In addition, the strength of each rule’s inference is 
specified by certainity factor (CF) in the range -1 to +1. CF ’ s 
will be discussed in the next section. Each rule in MYCIN falls 
into one and only one of the following categories: 

(1) Rules that may be applied to any culture. 

(2) Rules that may only be applied to current cultures. 

(3) Rules that may be applied to current organisms. 

(4) Rules that may be applied to any antimicrobial agent 

administered to combat a specific organism. 

(5) Rules that may be applied to operative procedures. 

(6) Rules that are used to order the list of possible 
therapeutic recommendations. 

(7) Rules that may be applied to any organism. 
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(8) Rules that may be applied to the patient. 

(9) Rules that may be applied to drugs given to combat 

prior organisms. 

(10) Rules that may be applied only to prior cultures. 

(11) Rules that may be applied only to organisms isolated 

in prior cultures. 

(12) Rules that store information regarding drugs of 

choice . 

The system also contains a collection of clinical 

par ame ters, represented as <attribute, object, value> triples. 
Th ese clinical par ame ters fall into six categories: 

(1) Attributes of cultures. 

(2) Attributes of administered drugs. 

(3) Attributes of operative procedures. 

(4) Attributes of organisms. 

(5) Attributes of the patient. 

(6) Attributes of therapies being considered for 
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rec onxnenda t i on . 

Each of the parameters has a certainty factor reflecting the 
system’s "belief” that the value is correct and an associated set 
of properties that is used during consideration of the parameter 
for a given context. These properties specify such things as the 
range of expected values a property ma y have, the sentence to 
transmit to the user when requesting data from him, the list of 
rules whose Premise references the parameter, the list of rules 
whose Action or Else clause permits a conclusion to be made 
regarding the parameter, etc. Only those properties that are 
relevent to each parameter are assocated with it. However, 
properly specifying how the parameter is to be represented in 
English is mandatory for all. 

Additional information is contained in simple lists that 
simplify references to variables and optimize knowledge storage 
by avoiding unnecessary duplication. These lists contain such 
things as the names of organisms known to the system and the 
names of normally sterile and non-st erile sites from which 
organisms are isolated. 

In conjunction with a set of four special functions, MYCIN 
uses knowledge tables to permit a single rule to accomplish a 
task that would otherwise require several rules. The knowledge 
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tables contain a record of certain clinical parameters and the 
values they may take on under various circumstances. 

There is one knowledge source in MYCIN that is as a set of 
functions. This is the knowledge required for choosing the 
apparent first-choice drug to be r e c oirmended . 

This constitutes the majority of MYCIN’s knowledge base, 
which permits the system to comprehend the nature of an infection 
without complete information about the organism involved and 
provide the physician with proper advice regarding treatment 
under the circumstances. This organization and structure, along 
with the way the knowledge is used facilitates the system’s 
ability to explain its actions and advice. 


MYCIN’s cognitive engine is domain independent in the sense 
that none of the knowledge required to proide advice about 
bacteremia is embedded in it. Thus, additional rules concerning 
infectious disease may readily be added, or a new knowledge base 
could be " substituted to provide therapeutic advice about a 
different d oma in of infections. 

The task that MYCIN performs, under the control of its CE, 
can be characterized as a four-step decision process: 
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(1) Decide which organisms, if any, are causing 

significant disease. 

(2) Determine the likely identity of the significant 
organi sms . 

( 3 ) De c i d e wh ich drugs are potentially useful. 

(4) Select the best drug or drugs. 

A consultation session between a physician and MYCIN results 
from a simple two step procedure: 

(1) Create the patient "context” as the top node in the 
cont ext tree. 

(2) Attempt to apply the "goal-rule” to the newly created 
context . 

The "goal-rule” is one of the rules from the category of 
those that may be applied to the patient (as described above), 
and state's: "If there is an organism that requires therapy and 

consideration has been given to the possible existence of 
additional organisms requiring therapy, even though they have not 
been recovered from any current cultures, then do the following: 
Compile a list of possible therapies which, based upon 
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sensitivity data, may be effective against the organisms 
requiring treatment and determine the best therapy reconmended 
from the compiled list; otherwise, indicate that the patient 
does not require therapy.” 

This rule follows the four-stage decision process given 
above . 

The two components or programs that constitute MYCIN’s CE 
are called MONITOR and FINDOUT. MONITOR’S function is to 
determine whether the conditions stated in the Premise of a rule 
are true. To do so, it considers each condition of the Premise 
at hand, first determing whether it has all of the necessary 
information to make the determination. If it requires 
information, it calls FINDOUT to obtain what is needed. FINDOUT 
first determines whether the needed information is laboratory 
data. If it is, it asks the physician for it. If the physician 
cannot provide it, FINDOUT retrieves the list of rules that may 
aid in deducing the information and calls MONITOR to evaluate the 
rules. When the process completes, control is returned to 
MDNITOR. *Tf the information needed is not laboratory data, 
FINDOUT retrieves the list of rules that may aid in deducing the 
needed information and calls MDNITOR to evaluate the rules. If 
the deductive process of applying the rules (backward from a goal 
to the data or information needed) cannot provide the needed 
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information, the physician is asked to provide it. In either 
case, control is returned to MONITOR. Given the information that 
is provided by FINDOUT or that was already available, MONITOR 
determines whether the entire Premise is true. If it is not, and 
there is no Else clause, the rule is rejected. If the Premise is 
true or the Else clause is invoked, the conclusion stated in the 
Action of the rule or in the Else clause is added to the ongoing 
record of the consultation, and the process completes. Note that 
there is a recursive relationship between MONITOR and FINDOUT, 
such that so long as any information is needed to evaluate a 
Premise, or rules are required to develop the needed information, 
the two components are in a recursively dependent and oscillating 
relationship until the very first rule invoked, the "goal-rule”, 
is satisfied. In the process of evaluating the rules, a great 
deal of related and necessary information and data are developed 
and retained in various tables and structures in the workspace. 
They serve two purposes: 

(1) They prevent wasted effort that would be required to 
redevelop information that has already been obtained, 
and to prevent the system from endlessly chasing its 
tail. 

(2) They provide the necessary history required for the 
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explanations that may be requested by the user. 

In addition to having certainty factors (CFs) for the rules 
and the clinical parameters in the knowledge base, the physician, 
when asked for either laboratory data or other information that 
the system itself cannot deduce, may attach a CF to his input. 
The default, if the physician does not provide a CF , is assumed 
to be +1. The certainty factors are the key to permitting MYCIN 
to perform inexact reasoning. The rationale, mathematics, and 
application are thoroughly treated in [Shortliffe, 76]. The 
presentation here is very s imp 1 i f i e d . 

A certainty factor (CF) is a number between -1 and +1 that 
reflects the degree of belief in a hypothesis. Positive CFs 
indicate that there is evidence that the hypothesis is valid; the 
larger the CF , the greater the degree of belief. A CF = 1 
indicates that the hypothesis is known to be correct. A negative 
CF indicates that the hypothesis is invalid; CF = -1 means that 
the hypothesis has been effectively disproven. A CF - 0 means 
either that there is no evidence regarding the hypothesis or that 
the evidence is equally balanced. The hypotheses in the system 
are statements regarding values of clinical parameters for the 
nodes in the context tree. To properly perform, MYCIN must deal 
with competing hypotheses regarding the value of its clinical 
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parameters. To do so, it stores the list of competing values and 
their CF s for each node in the context tree. Positive and 
negative CF s are a c c umu lated separately as me asures of belief 
(MB) and measures of disbelief (MD) and added to form a resultant 
CF for a clinical parameter. The CF of a conclusion is the 
product of the CF of the rule that generated the conclusion and 
the tally of the CFs of the clinical parameters that were used in 
substantiating the conclusion. When a second rule supports the 
same conclusion, the CFs are combined by z = x + y(l-x), where x 
is the CF of the first supporting rule, y is the CF of the 
succeeding rule and z is the resultant CF for the conclusion. 
The CFs permit the system to report findings to the physician 
with varying degrees of certainty such as, ’’There is strongly 
suggestive evidence that ....”, ’’There is suggestive evidence 
that ....”, ”There is weakly suggestive evidence that ....”, etc. 

Context Tree . The topmost tree is always the patient. 
Branches are added successively to the existing nodes as FINDOUT 
discovers a need for them in attempting to obtain requested 
information for MONITOR. Thus, given only the patient, when 
MDNITOR requests information from FINDOUT about organisms in 
order to evaluate the first condition in the Premise of the 
goal-rule, FINDOUT discovers that it cannot get organism 
information without having information about cultures. Thus, 
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context(sT concerning cultures(s) are spawned from the patient 
node, from which eventually are spawned contexts for the 
organisms identified by the cultures. For those organisms deemed 
significant, links attach to context nodes about the relevant 
drugs for treating these organisms. Thus, the context tree is 
tailored for each patient as the system progresses through its 
reasoning process. 

MYCIN’ s Explanat ions 

One of the primary design consideration taken in MYCIN was 
the requirement that the system be able to explain its decisions 
if physicians were going to accept it. Selecting rules as the 
representation of the system’s knowledge greatly facilitated the 
implementation of this capability. The physician using the 
system enters the explanation subsystem automatically when the 
consultation phase is completed, or he may enter it upon demand 
during the consultation session at any point at which the system 
requests input from him. In the latter case, he can input **VdIY” 
to request a detailed answer about the question just asked of him 
or he can 'Fnput ”QA” to enter the general question-answering 
explanation subsystem to explore the decisions and other aspects 
of the consultaion up to the point of divergence. 

The explanation provides several options to the physician. 
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Since the'system automatically enters this mode at the end of the 
consultation, the physician may simply input “STOP”, which 
terminates the system. He may input ’’HELP”, which provides him 
with the list of explanation options, which include: 


I nput 
EQ 


PR 

IQ 


Opt ion 

Explain a specific question asked of the 
physician during the consultation - each has a 
sequence n umb e r , wh i c h mu s t a c c omp a ny the EQ 
request . 

Requests a particular rule be printed and must be 
followed by the rule number. 

Is a prefix for a question about information 
acquired by the system during the consultation. 
The question is phrased in the limited English 
that MYCIN can handle. 


no prefix A general question is assumed being asked about 
the content of MYCIN’ s rules. 


Thus, the physician can ask to have Question 48 explained by 
inputting ”EQ48”. To which the system would respond: QUESTION 

48 WAS ASKED IN ORDER TO FIND OUT THE PATIENT’S DEGREE OF 
SICKNESS (ON A SCALE OF 4) IN AN EFFORT TO EXECUTE RULE068. He 
may then optionally input ”PR68” or ”V\HAT IS RULE068” to see what 
exactly was being sought and why. 

MYCIN’ s Interfaces 

MYCIN has two interfaces. One is for the using physician. 
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through which he may answer questions posed by the system and ask 
questions of it; the other is a knowledge-acquisition interface 
accessible only to experts recognized as such by the system. 

All of the questions asked of the user have been carefully 
designed not to require the language-understanding component. 
Thus, instead of asking, "What is the infectious disease 
diagnosis for the patient?” it asks, "Is there evidence that the 
patient has a meningitis?” To which only a simple "yes” or "no" 
i s r equ i red . 

The knowledge-acquisition interface, on the other hand, 
permits the expert to input a new rule in stylized English, with 
prompting to obtain the rule in the proper sequence: Premise 
first, condition by condition, followed by the Action, and then 
an Else clause if one is required. The system then translates 
the rule into internal form, reordering the conditions of the 
Premise if necessary, according to a set of criteria developed to 
improve the rule-evaluation process. It then retranslates the 
rule into English and requests that the expert decide whether the 
rewri tten --vers ion was the one intendend. If not, the expert may 
modify selected parts and is not required to restate the entire 
rule unless there has been a gross misunderstanding. 

The same mechanism is used when an expert wants to correct 
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or modify-an existing rule. In all cases, when a new or 
corrected rule has been approved by the expert, the system checks 
to see whether the rule is consistent with the existing rule set. 
If the new or modified rule subsumes or is subsumed by an 
existing rule, it is not readily discoverable, and no test is 
made for this condition. If a rule is discovered to be in 
conflict with an existing rule, it is rejected. 
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